Skip to main content

Setup

1. Prepare the debugging target​

First we need an application to be used as a debugee (app being debugged). Rather than creating such application sufficiently complex to illustrate debugging practices, we will use the well known application, built in the course of the Redwood Tutorial. This application (Redwood Blog) exists in this repository, and we will build it using the information from what's Next Redwood Tutorial section.

Make a local clone and run it, using the commands defined in the section using the example repo of the Redwood Tutorial. The commands to build this app are copied below for your convenience

git clone https://github.com/redwoodjs/redwood-tutorial.git
cd redwoodblog
yarn rw prisma migrate dev
yarn rw prisma db seed
yarn rw g secret
yarn rw dev

resulting with the front end of the Redwood Blog application running in the browser

image
Image 1 - running `yarn rw dev` in the terminal (on the left)


2. Setup the Chrome debugger​

We are describing the latest approach available since August 2022 which greatly simplifies access to Authored and Deployed code as explained in the article Modern web debugging in Chrome DevTools.

1. Setup:​

We will use the setup depicted below, and explained immediately after:

image
Image 1:
Invoking `yarn rw dev` in the terminal (Red marker 1)
starts the browser running the blog app (Red marker 2)
Devtools panel (Red marker 3) started as explained below


Having the Redwood Blog app running in the browser (Image 1, above), invoke the DevTools from the browser menu by pressing the F12 key (the DevTools panel is set to be outside and on the left of the browser window, as shown on the image 2)

image
Image 2 - invoking DevTools panel to be outside the browser


Click on the Devtools settings icon, then select the Experiments category and click the "Group sources into Authored and Deployed trees" checkbox, as shown on the image 3 below:

image
Image 3 - select "Group sources into Authored and Deployed trees"


3. Definition of a typical session​

(see Image 4 below)​

The Terminal (Red marker 1, left-most) is nearly completely hidden, since we will not use it once the Blog app is started (yarn rw dev). Similarly, the Browser (Red marker 2) exposes only the "Reload this page" button, that will be used whenever we want to restart the debug session. The layout shown on the image 4 below, renders the browser panel mostly covered by the DevTool panel, where all debugging action takes place

Note: the green rectangle marked Sources panel is selected on the top Devtools menu bar. In order to ensure maximim benefits of the Chrome Debugger (Devtoos) learn about all new features available, like view files, edit CSS and JavaScript, Create, save, and run Snippets and Set up a Workspace.

image
Image 4


Area 1 (Green marker 4)

  • Shows the application tree view in two structures - Authored and Deployed.
  • We will use the Authored view in the subsquent descriptions of the debugging exercises.

Area 2 (Green marker 5)

  • Debugger rendering of the selected code (Article.js) in the Authored view (Green marker 4) section of the source tree.
  • Depicts the source code view of the item selected in the application tree view (Area 1). The source code is rendered as originaly written Javascript / Typescript code.

Area 3 (Green marker 6)

  • Presents the detailed information about the context of the currently hit breakpoint:

    • list of defined watch variables
    • list of existing breakpoints
    • current application scope
    • call stack
    • list of enabled XMR/fetch breakpoints
    • list of DOM breakpoints
    • list of global listeners
    • list of event listeners breakpoints
    • list of CSP violation breakpoints

4. Example of use​

Let's finish this Setup Chrome DevTools debugger section by showing how to set a breakpoint in the Article.js component. In order to illustrate the stepping process, we will set the breakpoint at the line 8. This situation, rendered by the Chrome debugger is depicted on Image 5, below:

image
Image 5 - example debugging Article.js component


Green marker 1 shows the authored section of the source tree, with the component Article.js selected (green marker 2) and rentered in the source panel (green marker 3). Note that the only breakpoint (green marker 4) is set at line 8, which is also shown in the breakpoints list (green marker 6). The top of the right panel (detailed information about the context of the currently hit breakpoint) states that the debugger is paused (because it hit the breakpoint at line 8 - green marker 5). Finally, we can see the Local Scope panel, (green marker 7) renderig the local variable Article.

The next two screenshots show the Closure and Global scope at this specific breakpoint.

image
Image 6 - Closure


image
Image 7 - Global scope


In addition to this information we could define a set of watch variables, watch / breakpoint on threads, set DOM breakpoints, XHR/fetch breakpoints, set Event listener breakpoints and few other pieces of information. The section on using the Chrome debugger for Tracing Authentication code in our debugging target application provides more details on using these debugger features.

5. Setup Visual Studio Code debugger​

6. Example of use​


image